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DETAILED ACTION 

1 . This action is responsive to the Applicant's response filed 7/17/2006. 

As indicated in Applicant's response, claims 98, 105 have been amended. Claims 96-1 13 
are pending in the office action. 

Claim Rejections - 35 USC § 101 

2. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

3. Claims 96-1 13 rejected under 35 U.S.C. 101 because the claimed invention is directed to 
non-statutory subject matter. 

The Federal Circuit has recently applied the practical application test in determining whether the claimed 
subject matter is statutory under 35 U.S.C. § 101. The practical application test requires that a " useful, 
concrete, and tangible result" be accomplished. An "abstract idea" when practically applied is eligible for a 
patent. As a consequence, an invention, which is eligible for patenting under 35 U.S.C. § 101, is in the 
"useful arts" when it is a machine, manufacture, process or composition of matter, which produces a 
concrete, tangible, and useful result. The test for practical application is thus to determine whether the 
claimed invention produces a "useful, concrete and tangible result". 

Specifically, claims 96 recites a method for designing software system, comprising 
defining design parameters (DP) parameters, decomposing set of functional requirements (FR) 
and said parameters to create hierarchy thereof, defining a matrix for mapping parameter and 
requirements of such hierarchy, and use the matrix to further define object oriented structure 
wherein a FR represents an OO object and a DP represents a input to said object. The claim as a 
whole amounts to defining a software structure with descriptive elements representing parts of 
the software structure. The final result thus conveyed does not reasonably teach that a tangible 
and concrete real-world result has been generated at the end of the method steps leading to 
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defining of a software structure; that is, such structure remains but an abstract entity internal to a 
definition process, hence not materialized out into a reasonable real-world useful entity based on 
actual data transformation by hardware supported means other than a mere definition process, 
which appears to be just a internal or abstract function. The claim for failing to convey the 
yielding of a concrete, useful and tangible result, is rejected for leading to a non-statutory subject 
matter. 

Claim 105, similar to claim 96, amounts to defining a structure without any further 
teaching on any practical use of the structure in order to yield a real world useful result. And in 
light of the rationale as set forth above, claims 97-104, and 105-1 13 are rejected for the 
deficiency of not fulfilling the Practical Application requirement. 

Claim Rejections 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

5. Claims 96-1 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Nam P. 
Suh, "Axiomatic Design Theory for Systems", Research in Engineering Design, Vol. 10: pp. 
189-209, MIT, 1998 (hereinafter Suh_l), further in view of Sung-Hee Do and Nam P. Suh, 
"Systematic OO Programming with Axiomatic Design", IEEE Computer, Vol. 32, No. 10, Oct 
1999, Integrated Engineering, pp. 121-124 (hereinafter Suh_2). 

As per claim 96, Suh_l discloses a method of designing a software system, comprising: 
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defining a set of functional requirements that describe what the software system is to 
achieve (e.g. FRs - Fig. 1- pg. 195; Fig. Al 5 pg. 204; ch. 4.1, pg. 191); 

defining a set of design parameters, where each design parameter in the set satisfies at 
least one of the functional requirements ( DPs - Fig. 1, pg. 195; Fig. Al - pg. 204); 

decomposing the set of functional requirements and design parameters to create hierarchy 
of functional requirements and a hierarchy of design parameters (e.g. FR and DP hierarchies - 
Fig. 1 5 pg. 195; chp. 6.1->6.3, pg. 194-196), wherein at least one functional requirement of the 
set of functional requirements is a parent functional requirement at a first level in the hierarchy 
of functional requirements and is decomposed into at least two child functional requirements at a 
second level in the hierarchy that is below the first level, and wherein the at least two child 
functional requirements collectively accomplish the parent functional requirement ( see FR1 -> 
FR11, FR12-Fig. 1;, step 1: FRs mapping DPs, ch. 4.2^ 4.4, pg. 191-193); 

defining a design matrix that maps each design parameter in the hierarchy of design 
parameters to the at least one functional requirement in the hierarchy of functional requirements 
that the respective design parameter satisfies (e.g. ch. 4.2-> 4.4, pg. 191-193; chp. 6.1->6.3, pg. 
194-196); and 

using the design matrix to define software modules ( Fig. 2-4, pg. 196; ch. 6.4 pg. 197) of 
the software system, wherein at least one functional requirement in the hierarchy of functional 
requirements represents a software object of the software system (e.g. Fig. 3, pg. 196; modules 
Ms - ch. 6.6, pg. 198; ch. 7, pg. 199), and wherein at least one design parameter in the hierarchy 
of design parameters represents an input to the software object (e.g. input to Ml 231 - right col., 
ch. 6.2, pg. 195; ch. 6.4 pg. 197). 
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But Suh_l does not explicitly disclose that the FR-derived modules being designed from 
the matrix object are object-oriented structures. The concept of modularization of software 
architecture with parent/child relationship (see ch. 6.1 pg. 194 to ch. 6.4, pg. 197; Fig. 1,3,4) 
considered by Suh_l along with reassembling of modules from a database ( see ch. 6.7, pg. 199) 
and reusability implemented via library of software modules ( see ch. 8.1, pg. 200) suggest the 
known benefits of object-oriented implementation of large software systems at the time the 
invention was made, some of which being tracking of changes ( or failures) and understanding 
interaction dependency between modules ( see Suh_l, ch. 10, pg. 203). Suh_2, in a similar 
approach to implement axiomatic design to large systems analogous to Suh_l, teaches the same 
decomposition of levels of software modules via matching of DP/FR using a control matrix; and 
based upon the module derivation, teaches identification of classes as well as its interfaces, and 
attributes or methods thereof to represent a DP ( see Fig. 1, pg. 122; middle column, pg. 124). 
Based on the concept of independent reassembling of modules per development instance and 
reusability control from Suh_l, it would be obvious for one skill in the art at the time the 
invention was made to implement Suh_l modules associated with each FRs, so that these 
modules are reuse object-oriented classes or interfaces as taught by the approach by Suh_2, 
because the creation of OO or classes instances as they are retrieved from reuse can support 
relationships ( as in a interface) between object classes and object operations, such that existing 
designs can be reused to support further decomposition, and/or creation of new designs, or to 
help diagnose or handle tracking due to software change ( see Suh_2: middle pg. 121; middle 
para, pg. 124). 
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As per claim 97, Suh_l teaches software modules representing equivalent of hardware 
assemblies ( ch. 4.2 pg. 191) to match functional requirements, but does not explicitly disclose 
that at least one element of the design matrix and the at least one design parameter represents an 
operation performed by the software object; but in view of the classes and method teaching from 
Suh_2 as set forth above, the operation limitation, i.e. a method by a software object in light of 
00 implementation from above, would have been obvious. 

As per claim 98, Suh_l discloses that wherein the act of defining the set of define 
parameters further comprises determining the set of design parameters by mapping the set of 
functional requirements into a physical implementation domain (e.g. Fig. Al, pg. 204). 

As per claims 99-100, Suh_l discloses an act of determining if the design matrix is 
decoupled (eq. 15, pg. 197); and is not decoupled, manipulating the design matrix into lower 
triangular form (e.g. middle matrix line 2, 7; eq. 15, pg. 197). 

As per claim 101, Suh_l ( in view of Suh_2) discloses wherein the at least one 
functional requirement that represents a software object includes at least two functional 
requirements, and wherein a first of the at least two functional requirements represents a first 
software object and a second of the at least two functional requirements represents a second 
software object (e.g. Fig. 1, ch. 6.1-pg. 194-195; ch. 6.6. pg. 198; ch. 4.5 pg. 193). 

As per claim 102, Suh_l discloses defining a relationship between the first software 
object and the second software object using a junction* (e.g. Fig. 2-3, pg. 196). 

As per claim 103, Suh_l discloses defining a third software object by combining the first 
software object and the second software object according to a type of the junction (e.g. Fig. 2-4, 
pg. 196). 
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As per claim 104, Suh_l discloses wherein the type of the junction is one of: a 
summation junction; a control junction 1 , or a feedback junction (e.g. Fig. 2-4, pg. 196). 

As per claim 105, Suh_l discloses computer readable medium encoded with instructions 
that, when executed on a computer system, perform a method of allowing a user to define a 
software system (e.g. software systems - Introduction, pg. 189), the method comprising allowing 
the user to: 

define (a set of functional requirements . . .); 
define (a set of design parameters); 

decompose (the set of functional requirements and design parameters . . .); 
define (a design matrix that maps . . . ); and 

using the design matrix (to define software modules. . .) as recited in claim 96. 
Thus, all of which limitations are respectively addressed according to the rejection set 
forth in claim 96. 

But Suh_l does not disclose that the software modules are to define an object-oriented 
structure. However, this limitation has been addressed as obvious in claim 96. 

As per claims 106-113, these claims correspond to the claims 97-104 for reciting the 
same subject matter therein respectively; hence are rejected using the rationale set forth therein, 
correspondingly. * 

Claim Rejections - 35 USC § 102 
6. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 1 02 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 
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j (a) the invention was known or used by others in this country, or patented or described in a printed publication in this 
or a foreign country, before the invention thereof by the applicant for a patent 

7. Claims 96-1 15 are rejected under 35 U.S.C. 102(a) as being anticipated by Nam P Suh, 
Axiomatic Design of Software, copyright @ August 22, 1999, chapter 5, pp. 2-74 ( hereinafter 
SuhNam - submitted with IDS filed 7/17/2006). 

As per claim 96, SuhNam discloses a method of designing a software system, 
comprising: 

defining a set of functional requirements that describe what the software system is to 
achieve (e.g. ch. 5.2.1, pg. 8-12); 

defining a set of design parameters, where each design parameter in the set satisfies at 
least one of the functional requirements (e.g. ch. 5.2.1, pg. 8-12, subpara (i) -> (iv) ); 

decomposing the set of functional requirements and design parameters to create hierarchy 
of functional requirements and a hierarchy of design parameters (e.g. 5.2.1, pg. 8-12, subpara (i) 
-> (iv); ch. 5.3. pg. 14-24 ), wherein at least one functional requirement of the set of functional 
requirements is a parent functional requirement at a first level in the hierarchy of functional 
requirements and is decomposed into at least two child functional, requirements at a second level 
in the hierarchy that is below the first level, and wherein the at least two child functional 
requirements collectively accomplish the parent functional requirement (e.g. ch. 5.3, pg. Pg. 14- 
24; Fig. Ex 5.1. a; step 4, pg. 16); 

defining a design matrix that maps each design parameter in the hierarchy of design 
parameters to the at least one functional requirement in the hierarchy of functional requirements 
that the respective design parameter satisfies (e.g. ch. 5.3, pg. Pg. 14-24 ); and 
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using the design matrix to define an object-oriented structure (e.g. ch. 5.4 - pg. 36-55 ) of 
the software system, wherein at least one functional requirement in the hierarchy of functional 
requirements represents a software object of the software system (e.g. ch. 5.4 - pg. 36-55), and 
wherein at least one design parameter in the hierarchy of design parameters represents an input 
to the software object (e.g. step 4, pg. 16; ch. 5.4.3 pg. 41-51). 

As per claims 97-104, see ch. 5.2.1, pg. 8-12, subpara (i) ^ (iv); ch. 5.3. pg. 14-24; ch. 
5.4 - pg. 36-55; ch. 5.6, pg. 58-65) 

As per claim 105, SuhNam discloses computer readable medium encoded with 
instructions that, when executed on a computer system, perform a method of allowing a user to 
define a software system, the method comprising allowing the user to: 

define (a set of functional requirements . . .); 

define (a set of design parameters); 

decompose (the set of functional requirements and design parameters .. .); 
define (a design matrix that maps . . . ); and 

using the design matrix .(to define software modules. . .); all of which steps as recited in 

* 

claim 96. 

Thus, all of which limitations are respectively addressed according to the rejection set 
forth in claim 96. 

As per claims 106-113, these claims correspond to the claims 97-104 for reciting the 
same subject matter therein respectively; hence are rejected using the rationale set forth therein, 
correspondingly. 

Response to Arguments 
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8. Applicant's arguments submitted 7/17/2006 with respect to claims 96-1 13, have been 
considered but are moot in view of the new ground(s) of rejection. 

Conclusion 

9. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki can be reached on (571)272-3719. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 
272-3609. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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